REMARKS 



Claims 1-27 are pending. Claims 1-13 and 17-27 including independent claims 1, 17, 
and 25 were rejected under 35 U.S.C. 103(a) as being unpatentable over Zaidi (2002/0038401 
Al) in view of Heinkle (2004/0015739 Al). The Examiner also rejected claims 1-27 under 35 
U.S.C. 101 and it is unclear whether the Examiner is maintaining this rejection. 

The Examiner rejected independent claims 1, 17, and 25 under 35 U.S.C. 103(a) as being 
unpatentable over Zaidi in view of Heinkel. However, Zaidi and Heinkel, even if appropriately 
combined, do not teach or suggest generating a plurality of test designs that allow testing of a 
design automation tool. Although the claims are believed allowable in their current form, the 
claims are being amended to facilitate prosecution. More specifically, claims 1, 17, and 25 have 
been amended to recite "selecting a plurality of submodules from a design module library, 
wherein cost constraints are used to select the plurality of submodules." This amendment is 
believed supported in Figure 6 and associated description. More specifically, "At 609, cost 
constraints are applied as needed to reduce the set of selected modules. For example, if a device 
class supports only two kilobytes memory, no more than two kilobytes worth of memory 
modules will be selected." (page 15, lines 19-22) 

None of the references cited by the Examiner are believed to teach or suggest this 
recitation. Neither Zaidi nor Heinkle teach or suggest selecting a plurality of submodules from a 
design module library. Furthermore, neither Zaidi nor Heinkle teach or suggest using cost 
constraints to select the plurality of submodules. 

Dependent claim 4 has been amended to recite "wherein instantiation constraints are used 
to select the plurality of submodules." This amendment is believed supported in Figure 6 and 
associated description. More specifically, "At 611, maximum instantiation constraints are 
applied to further reduce the set of selected modules. For example, a particular device may be 
limited to two DSP cores." (page 15, lines 22-24) Neither Zaidi nor Heinkle teach or suggest 
using instantiation constraints to select the plurality of submodules. 

The Examiner argues that Zaidi describes generating multiple test designs in paragraph 
[0037]. The Applicants respectfully disagree. Zaidi describes in paragraph [0037]. "Most of the 
block design directories containing RTL source code have a separate subdirectory structure 
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underneath, e.g., "cpubr/", "cpumem/", "dma/", "intctl/", "led/", "mc/", "palmbus/", "pio/", 
"sysctl/", "timer/", and "uart/". The "<block>/sim/" subdirectory includes the simulation tests for 
the design. The "<block>/synop/" subdirectory includes the Synopsys synthesis scripts and 
output files for the design. The "<block>/vlog/" subdirectory includes the Verilog RTL source 
code for the design; if the embodiment language were VHDL, the "<block>/vhdl/" subdirectory 
includes the VHDL RTL source code for the design." 

Paragraph [0037] only describes where the source code for particular components is 
located. The Zaidi paragraph [0037] does not teach or suggest anything about generating 
multiple designs or generating test designs. 

The Examiner further points to paragraphs [0040] -[0041]. "Each design block has its 
own separate simulation directory, defined as "<block>/sim/" in the directory structure. Such 
directory includes all of the tests exercising that given block in the system. Simulations for the 
block can be run directly from this directory. Additional tests for the block can be placed into 
this directory and simulated. New blocks can be easily added into the same environment by 
adding the same directory structure consisting of the "<newblock>/vlog/" or 
"<newblock>/vhdl/", and "<newblock>/sim/" directories. Tests exercising this new block in the 
system would be placed in the "<newblock>/sim/" directory and executed from that directory." 

The \sim\ directory includes tests exercising this new block in the system. However, 
there is still no teaching in Zaidi of generating multiple test designs that allow testing of a design 
automation tool. Not only does Zaidi not teach or suggest generating the plurality of files in the 
/sim/ directory, but the files in the /sim/ directory are not a plurality of test designs. The Zaidi 
/sim/ directory includes multiple files used for testing a block. The Examiner's implication is 
that the multiple files for testing the block are generated. However, even if these multiple files 
are generated, these files are not "a plurality of test designs for testing the design automation 
tool." Zaidi is believed to provide multiple scripts, not test designs. The multiple scripts test 
only physical blocks such as "any blocks that interact with the main system buses or each other. 
[0040] Zaidi only possible describes simulations or scripts in the /sim/ directory. There are no 
generated multiple test designs. 

The Examiner also argues that Heinkel teaches generating multiple test designs in 
paragraphs [0057] - [0060]. However, paragraphs [0057] - [0060] only describes a single 



10/693,546 



7 



"device under test 50." Heinkel in fact does not teach generating a plurality of test designs 
because Heinkel is configured to test a single DUT (device under test) such as a single ASIC. 

By contrast, various embodiments of the present invention allow generation of multiple 
test designs to allow testing of a design automation tool. In one example, a test design can 
include a processor, a DSP core, a timer, and a network interface while another generated test 
design includes a processor, a cryptographic core, and a PIO, and a network interface. Top level 
modules are instantiated, submodules are parameterized, and interconnection logic is provided 
for each generated test design. It is respectfully submitted that neither Heinkel nor Zaidi teach or 
suggest these elements recited in the independent claims. 

According to various embodiments, there are test scripts and simulations that are used to 
test physical blocks. Both Heinkel and Zaidi possibly describe scripts and simulations that are 
used to test a physical block or a "new block." By contrast, the independent claims recite 
generating multiple test designs that allow testing of a design automation tool. 

The Examiner rejected claims 1-27 under 35 U.S.C. 101 because the Examiner argues 
that the claimed invention is directed to non- statutory subject matter. The Examiner argues that 
claims 1-16 are software per se and claims 1-27 do not produce a tangible result. The Applicants 
respectfully disagree with the Examiner's rejection. However, the claims have been amended to 
facilitate prosecution. Claims 1, 17, and 25 has been amended to recite "applying the plurality of 
test designs to test the design automation tool." 

It is noted that the Interim Guidelines for Examination of Patent Applications for Patent 
Subject Matter Eligibility (2005-10-26) states: In determining whether the claim is for a 
"practical application," the focus is not on whether the steps taken to achieve a particular result 
are useful, tangible and concrete, but rather that the final result is "useful, tangible and concrete." 
The Federal Circuit has provided further guidance in distinguishing between the judicially- 
created exceptions to patentable subject matter and eligible subject matter. The focus of the 
inquiry is whether the claim, considered as a whole, constitutes "a practical application of an 
abstract idea." State Street, 149 F.3d at 1373, 47 USPQ2d at 1600. 

Taken as a whole, the independent claims are directed at erifying the operability of a 
design automation tool. Generating each design includes instantiating an I/O structure, 



10/693,546 



8 



parameterizing multiple submodules, and providing interconnect logic. It is submitted that, 
taken as a whole, the independent claims provide a useful, tangible and concrete result in 
generated test designs that test design automation tools. According to various embodiments, the 
tests are physical, tangible, and useful files that verify operation of a design automation tool. 
Consequently, the non- statutory subject matter rejection is believed overcome. 

In light of the above remarks, the rejections to the independent claims are believed 
overcome for at least the reasons noted above. Applicants believe that all pending claims are 
allowable in their present form. Please feel free to contact the undersigned at the number 
provided below if there are any questions, concerns, or remaining issues. 



Respectfully submitted, 
BEYER WEAVER LLP 

/Godfrey K. Kwan/ 
Godfrey K. Kwan 
Reg. No. 46,850 

P.O. Box 70250 
Oakland, CA 94612-0250 
(510) 663-1100 
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